Exhibit G

To

iDomains Registry Operator’s Proposal

 

 

 

 

CORE SRS Protocol Specification 1.1

 


 

 

 

 

CORE Shared Registry System Protocol (SRSP)

Version 1.1

Klaus Malorny, Knipp Medien und Kommunikation

September 13th, 2000


 

1.  History......... 6

2.  Protocol Structure............ 6

2.1.  Transmission Layer.............. 6

2.1.1.  Digital Signatures... 7

2.1.2.  Transmission by E-Mail.. 7

2.1.3.  Transmission by TCP...... 7

2.1.4.  Payload Encoding.... 8

2.2.  Payload.. 8

2.2.1.  Registry Data Model........ 8

2.2.1.1.  The Domain Object.... 9

2.2.1.2.  The Contact Object.. 10

2.2.1.3.  The Host Object.. 10

2.2.1.4.  The Registrar Object.. 10

2.2.2.  Syntax................. 11

2.2.3.  Transaction Mechanism 12

2.2.4.  Common Request Keys................. 12

2.2.5.  Common Response Keys........ 12

2.2.6.  Acknowledge Responses 13

2.2.7.  Replies................. 13

2.2.8.  Requests and their Replies................. 13

2.2.8.1.  Complete Transfer Request 14

2.2.8.2.  Create Contact Request 15

2.2.8.3.  Create Domain Request 16

2.2.8.4.  Create Host Request 16

2.2.8.5.  Delete Contact Request 17

2.2.8.6.  Delete Domain Request 17

2.2.8.7.  Delete Host Request 18

2.2.8.8.  Inquire Contact Request 18

2.2.8.9.  Inquire Domain Request 20

2.2.8.10.  Inquire Host Request 21

2.2.8.11.  Inquire Registrar Request 22

2.2.8.12.  Modify Contact Request 24

2.2.8.13.  Modify Domain Request 24

2.2.8.14.  Modify Host Request 25

2.2.8.15.  Modify Registrar Request 25

2.2.8.16.  Query Request 26

2.2.8.17.  Renew Domain Request 27

2.2.8.18.  Status Request 27

2.2.8.19.  Transfer Domain Request 28

2.2.9.  Notifications................. 29

2.2.9.1.  Init-Transfer Notification............. 29

2.2.9.2.  Transfer-Acknowledge Notification............. 29

2.2.9.3.  Transfer-Finish Notification............. 29

2.2.10.  Common Data Types...... 30

2.2.10.1.  Handles 30

2.2.10.2.  Domain Names.. 30

2.2.10.3.  IP Addresses............. 30

2.2.10.4.  Dates/Times........... 30

2.2.10.5.  Phone and Fax Numbers 30

2.2.10.6.  E-Mail Addresses............. 30

2.2.10.7.  Billing Units.... 30

2.2.11.  Description of the Keys.. 30

2.2.11.1.  Action Key............. 30

2.2.11.2.  Address Keys.... 31

2.2.11.3.  Admin-Contact Key...... 31

2.2.11.4.  Approved-Owner-Change Key............. 31

2.2.11.5.  City Key 31

2.2.11.6.  Completed-Before Key............. 31

2.2.11.7.  Completed-Since Key............. 32

2.2.11.8.  Contact Key...... 32

2.2.11.9.  Costs Key............. 32

2.2.11.10.  Count Key............. 32

2.2.11.11.  Country Key...... 32

2.2.11.12.  Created Key...... 33

2.2.11.13.  Created-By Key...... 33

2.2.11.14.  Domain-Name Key............. 33

2.2.11.15.  Domain-State Key 33

2.2.11.16.  EMail Key............. 33

2.2.11.17.  Error-Code Key...... 33

2.2.11.18.  Error-Text Key...... 34

2.2.11.19.  Expiration-Date Key 34

2.2.11.20.  Fax Key 34

2.2.11.21.  FName Key............. 34

2.2.11.22.  Gaining-Registrar Key...... 34

2.2.11.23.  Handle Key............. 35

2.2.11.24.  Individual Key...... 35

2.2.11.25.  IP-Address Key...... 35

2.2.11.26.  Last-Modified Key...... 35

2.2.11.27.  Last-Modified-By Key 35

2.2.11.28.  List Key 35

2.2.11.29.  LName Key............. 36

2.2.11.30.  Managing-Registrar-ID Key...... 36

2.2.11.31.  Notification-Type Key............. 36

2.2.11.32.  NS-Host Keys.... 36

2.2.11.33.  Organization Key... 36

2.2.11.34.  Owner-Contact Key...... 37

2.2.11.35.  Owner-Contact-Origin Key............. 37

2.2.11.36.  Payload-Version Key...... 37

2.2.11.37.  Period Key............. 37

2.2.11.38.  Phone Key............. 37

2.2.11.39.  Postal-Code Key...... 37

2.2.11.40.  Reg-Admin-Auth-Key Key...... 38

2.2.11.41.  Reg-Admin-Auth-Key-Info Key 38

2.2.11.42.  Reg-Admin-Auth-Type Key...... 38

2.2.11.43.  Reg-Admin-Contact Key...... 38

2.2.11.44.  Reg-Admin-Permissions Key...... 38

2.2.11.45.  Reg-Agent-Auth-Key Keys.... 39

2.2.11.46.  Reg-Agent-Auth-Key-Info Key 39

2.2.11.47.  Reg-Agent-Auth-Type Keys.... 39

2.2.11.48.  Reg-Agent-Contact Keys.... 39

2.2.11.49.  Reg-Agent-Permissions Key...... 40

2.2.11.50.  Reg-State Key...... 40

2.2.11.51.  Reg-Super-Auth-Key Key...... 40

2.2.11.52.  Reg-Super-Auth-Key-Info Key 40

2.2.11.53.  Reg-Super-Auth-Type Key...... 40

2.2.11.54.  Reg-Super-Contact Key...... 40

2.2.11.55.  Reg-Super-Permissions Key...... 41

2.2.11.56.  Registrar-ID Key...... 41

2.2.11.57.  Request-Transaction-ID Key 41

2.2.11.58.  Request-Type Key............. 41

2.2.11.59.  Request-State Key 41

2.2.11.60.  Response-Type Key............. 42

2.2.11.61.  State Key 42

2.2.11.62.  Submitted-Before Key............. 42

2.2.11.63.  Submitted-Since Key............. 42

2.2.11.64.  Success Key...... 42

2.2.11.65.  Tech-Contact Key...... 43

2.2.11.66.  Time-Out-Date Key 43

2.2.11.67.  Title Key 43

2.2.11.68.  Transaction-Credit Key............. 43

2.2.11.69.  Transaction-ID Key 43

2.2.11.70.  Transfer-Approved Key...... 44

2.2.11.71.  Transfer-Performed Key...... 44

2.2.11.72.  Zone-Contact Key...... 44

2.2.12.  Error Codes....... 44

2.3.  Domain Transfer Process..................... 45

A. References... 48

B. Glossary...... 48

 


1.1. History

The original Shared Registry System Protocol (version 0.9) was developed by CORE together with Emergent, Inc. in the context of the creation of a registry system suitable for the registration of the anticipated seven new top level domains. Due to the political change, CORE was unable to start the registration of those domains. Instead, CORE got the opportunity to register COM, NET and ORG (CNO) domains via the registry spin-off of Network Solution Inc. As the infrastructure had already been set up and was working, CORE decided to extend the registry system instead of the development of a new system specific to CNO domains. The server system was extended to synchronize its database with NSIRegistry’s via the Registry Registrar Protocol (RRP). The payload of the SRSP was modified to conform to the new needs. The development was performed by Computer Service Langenbach GmbH, and the SRSP got the version number 1.0.

This document describes the version 1.1 of the protocol, which is mostly a cosmetic update of the payload and does not introduce much new functionality.

2.2. Protocol Structure

The protocol defines the communication between a client (operated by the registrar) and the server (operated by the registry). It is message-based, i.e. one side (either the server or the client), compiles a packet with its data (called payload) and sends it to the opposite side. The receive and transmit channels are not synchronized: The client does not need to wait for the server’s answer to send additional requests; the server does not need to send the responses immediately or in the order in which the client sent the requests. But it is guaranteed that the server does not send responses not related to the particular client, i.e. the client does not receive unexpected responses. Due to the transaction management, situations where the communication fails can be handled (see below for details).

The protocol consists of two layers. The transport layer defines the communication between the client and the server. It is also responsible for the client/server authentication and for the secure transmission of the payload data.

The payload represents the application layer. It defines the requests from the clients and the responses from the server. A built-in transaction management allows the processing of asynchronous, interleaved requests.

For the purpose of domain transfers, it is required that the registry can notify the registrar about certain events. This does not fit in mentioned request-reply schema. Therefore, the notification is handled separately, but by using the same technologies: The server uses the e-mail transmission variant for the notification. The destination e-mail address is a fixed address specified by the registrar. The format of the payload is the same, although different keys are used.

2.1.2.1. Transmission Layer

The transmission layer is responsible for the transfer of the payload to the server and back to the client. The SRSP defines two different variants for this transfer: by e-mail and by a TCP connection. In both cases, the authentication and the secure transmission is done by digital signatures[1]. The format of the signatures conforms to the standard defined by [PGP5].

2.1.1.2.1.1. Digital Signatures

For the attachment of the signature to the payload, the PGP specific variant of the S/MIME standards is used, as described in [RFC1847] and [RFC2015]. The following content-type specific attributes must be used in the context of this protocol:

micalg   pgp-sha1

protocol   application/pgp-signature

 

The keys must use the DSS/Diffie-Hellman algorithms. Keys of other types are not accepted. Depending on whether the message is sent to the server or to the client, it is signed by different keys.

On the server side, a registry specific key is used to sign the messages to the clients. On the client side, multiple keys can be used. There is a super contact with a corresponding key, which is maintained by the registry. An administrative contact and additional agents with their keys can be added by registrar at will (see modify registrar below).

2.1.2.2.1.2. Transmission by E-Mail

The PGP-signed payload is sent to a specific address at the registry. The registry uses the contents of the reply-to field or, if it does not exist, the contents of the from field specifies the e-mail address, to which the server’s response is sent back. The e-mail address is not used to authenticate the user — the registrar-id field together with the key used for the signature identifies and authenticates the user.

Due to the mechanisms behind the e-mail transport,  there is a risk of wrongly delivered e-mails and eavesdropping. Although protocol does not transport very sensitive data, it is recommended not to use this transmission method.

2.1.3.2.1.3. Transmission by TCP

In this variant, the messages are transported between client and server via a TCP connection. Port number 362/service name srssend has been assigned for that service [IANA-PORTS].

For transmission, the payload is signed according to the rules above. A message is constructed according to the syntactic rules specified in [RFC822] and [RFC1521], with the difference that the header consists only of MIME related fields, i.e., in relation to this application, exactly of the content-type field.

The message is sent through the TCP connection without additional information (length or termination mark). Since the outermost content-type is always a multipart type (multipart/signed), the body of the message always contains MIME boundaries. The reader can easily detect the end of the message by watching the input stream for the closing boundary (it differs from intermediate boundaries by two additional hyphens).

A typical message looks like this:

Content-Type: multipart/signed; micalg=pgp-sha1;
  protocol="application/pgp-signature"; PGPFormat="PGPMIME-signed";
  boundary="12027960_39A4DF56751968_1"

--12027960_39A4DF56751968_1
Content-Type: text/x-srs-data

payload-version: 1.1
transaction-id: 4084.968850757
registrar-id: CORE-326
request-type: inquire registrar
handle: CORE-326

--12027960_39A4DF56751968_1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGP 5.0i
MessageID: gA7PE4txVcbglLFpY14pt9BreT3zhESX

iQA/AwUBOaTfVibmObpCSbN4EQIN5wCg7cU9iCZyeGaXBqRkjFJyD550PpoAn3Mx
X/ur+CMmG+WfaeYQNOL73KgN
=sPqi
-----END PGP SIGNATURE-----

--12027960_39A4DF56751968_1--

2.1.4.2.1.4. Payload Encoding

The payload has the content-type text/x-srs-data. No MIME content transfer encoding or compression may be applied to the payload.

2.2.2.2. Payload

2.2.1.2.2.1. Registry Data Model

Before describing the requests of the client and the responses of the server, it is important to understand the model on which the registry operates.

The registry stores objects. An object is, in this context, a collection of related data. Four different object types exist: domains, contacts, hosts and registrars (explained later). Each object has a unique identifier. This identifier is either a certain part of the data (in case of the domain object, it is the domain name), or it is a unrelated text label, usually called handle.

 

object type

unique identifier

domain

the domain name, case insensitive

contact

text label COCO-N (where N is a positive number)

Host

text label COHO-N (where N is a positive number)

registrar

text label CORE-N (where N is a positive number)

 

Objects can reference each other, e.g. domains reference hosts for the purpose of specifying the name servers which manage the corresponding zones. Referenced objects cannot be deleted, as the referencing objects would become invalid. A change to a referenced object indirectly modifies all referencing objects[2], e.g., changing a host’s IP address results in a change of all domains referencing it: The next build of the registry’s master zone file would contain the new IP address for those domains.

The objects are shared among the registrars, i.e., any registrar can view or use any object. Domain, contact and host objects have a property of the managing registrar. Each of those objects is managed by the registrar who created it. The property restricts the right to modify a certain object: only the managing registrar may change it. The managing registrar of domains is changed during the transfer domain process. The managing registrar of contacts and hosts cannot be changed. Even in the case of a domain transfer between registrars, the contacts and hosts referenced in the domain stay at the loosing registrar. The gaining registrar can continue to use these contacts and hosts or it can create new ones and update the domain accordingly.

2.2.1.1.2.2.1.1. The Domain Object

The domain object stores the domain related data, which is

-      the domain name itself, fully qualified

-      the owner of the domain

-      the administrative, technical and zone contact of the domain (the tasks of these contacts is out of the scope of this document)

-      up to twelve hosts

-      the registration period in years

-      the state of the domain

The contacts (excluding the owner) and hosts are stored as references to the corresponding objects. The owner is directly stored in the domain object. It contains the data of a given contact object at the point of time of the creation or modification of the domain object. Later changes to the contact object do not modify the contents of the domain object. Although the domain object stores a reference to the owner contact object, the reference has only informational character: It just informs the registrar about the origin of the owner data.

The registration period determines how long the domain will operate without further interaction and how much is deducted from the registrar’s account.

The state has one of the four possible values:

reserved

the domain is registered but no entry is generated in the registry’s master zone file.

production

the domain is registered and fully functional

expired

the registration period has expired (the exact consequences are out of the scope of this document, limited modification rights may apply)

hold

the domain is currently matter of a dispute (the exact consequences are out of the scope of this document, limited modification rights may apply)

2.2.1.2.2.2.1.2. The Contact Object

The contact object stores the identity and various types of addresses of an individual or of an organization. It contains the following data:

-      a flag which identifies whether the contact is an individual or an organization

-      the first name, the last name and the title of the individual

-      the name of the organization

-      The "real world" address: two free form address lines (typically used for specification of the street, but may contain a more specific or different inner-city address), the city (including the postal code), the state and the country.

-      the phone number     (with international area code)

-      the fax number (with international area code)

-      the e-mail address

Although it should be avoided by the registrar, it is possible to create multiple contact objects for exactly the same person or organization.

2.2.1.3.2.2.1.3. The Host Object

The host object describes a name server, which is able to respond to DNS requests ([RFC1035]) for those domains which reference this object. The following data is stored in the object:

-      the domain name of the name server

-      the IP address of the name server (optional)

-      a reference to a contact object (identifying a person or organization, who/which is responsible for the name server; optional)

Although it should be avoided by the registrar, it is possible to create multiple host objects with the same domain name or IP address. Please note that the host object does not contain a reference to a domain object, so a domain object may be deleted even if a host exists that is located inside (in the sense of the domain name system) that domain.

2.2.1.4.2.2.1.4. The Registrar Object

The registrar object is maintained by the registry. Some parts of the data are exposed to the registrars, and a registrar is able to modify some aspects of his own data. The data which is exposed is:

-      the name and the handle of the registrar

-      the status (active, suspended or defunct)

-      the account balance

-      the super, administrative and agent contacts, along with PGP related information and permissions.

 

2.2.2.2.2.2. Syntax

The payload consists of readable text, encoded by the 7-Bit ASCII encoding. It represents a set of key-value pairs. A single key may appear multiple times. In this case, each appearance of the key represents an independent record and is not the continuation of a previous key-value pair. The order of differing keys is irrelevant. In the case of multiple identical keys, the order is important.

Two representations exist for a key-value pair. They differ only syntactically: the first variant is more suitable for single line entries. If it starts with a quote, that quote must be doubled to make the entry different to the second variant. The value may continue on the next line, but the newline must be prefixed by a backslash (the backslash/newline combination does not become part of the value). Whitespace that appears at the start or at the end of the value is ignored.

The second form is a multi-line form which is used for lengthy data, e.g. an ASCII encoded PGP public key. It starts and ends with a double quote. Any non double-quote character between them is allowed, even a newline. The quotes are not part of the value.

The key is case-insensitive.

The formal grammer of the payload is:

payload ::= kv-pair*

kv-pair ::=                 key whitespace* : value newline | newline

value ::=                   value1 | value2 | whitespace*

value1 ::=                 value1start value1other*

value1start ::= value-char | "" | \ newline

value1other ::= value-char | " | \ newline

value2 ::=                 " value2char+ "

value2char ::= value-char | newline | \

value-char[3] ::= whitespace | ! | [0x23 .. 0x5B] | [0x5D .. 0x7E]

key ::=                       key-char+

key-char[4] ::= [0x21 .. 0x39] | [0x3B .. 0x7E]

newline ::= 0x0D | 0x0D 0x0A | 0x0A

whitespace ::= 0x20 | 0x09

(name denotes a non-terminal symbol, | separates alternatives, x denotes a literal character or character sequence, 0xNN the hexadecimal code of a character, [ from .. to ] a sub-range of the ASCII character set, ? zero or one occurrences, + one or more occurrences, * zero or more occurrences)

2.2.3.2.2.3. Transaction Mechanism

The protocol uses transaction identifiers to enable the tracking of requests. The transaction identifier is specified by the client via the transaction-id key. The server uses that identifier in every response, so the client can associate these responses to the corresponding requests.

The server reacts to a normal request by sending two responses. The first is an acknowledge (response-type: ack) and is sent immediately after the reception at the server. After the processing of the request, the server sends the results back to the client (response-type: reply).

In both transmission variants (e-mail and TCP), it may happen that the communication fails — either the e-mail is lost or the TCP connection is interrupted, maybe just in the moment of sending a request or receiving a response. In the case of requests which do not modify the state of the registry, the client has to repeat the request, since the server does not back up the results of such requests.

For requests that modify the state of the registry, the server saves the results of processed requests for a certain time, at least for a day. Two special request exist to help the client on its recovery: With the status request, the client is able to retrieve the status of a specific request. The server responses either with the result of the request, with the current processing state or with the information that no request with the given transaction identifier exist (either the request has not yet been received or it is lost).

The other special request is the query request. By this request, the client can ask the server to send back a list of transaction identifiers of requests, whose submission or completion time falls in a specified period and that have the specified processing state.

Each registrar has its own name space for the transaction identifiers. Therefore it is not possible to request information about transactions of different registrars.

2.2.4.2.2.4. Common Request Keys

All requests sent to the server must contain at least the following four key: registrar-id, payload-version, transaction-id and request-type.

The registrar-id key identifies the registrar. It is also used for authentication in combination with the signature of the transmission layer.

the payload-version key enables the server to identify the version of the payload and to react differently to different client software versions.

The transaction-id key represents the transaction identifier of the request, as discussed above.

The request-type key describes the action the server should perform on behalf of the client.

2.2.5.2.2.5. Common Response Keys

All responses sent from the server contain at least the following three keys: registrar-id, transaction-id and response-type.

The registrar-id identifies the registrar, whose request is replied.

The transaction-id identifies the request the response corresponds to.

The response-type tells whether the response is an intermediate (acknowledge) or the final response (reply).

2.2.6.2.2.6. Acknowledge Responses

The acknowledge response is immediately sent by the server to notify that the request has been received, that it is syntactically correct, that the client authentication was successful, that it conforms so far to the protocol and that it can be queued for processing. It does, however, not give any clues whether the processing of the request will succeed or fail. If one of the conditions above is not satisfied, a reply is sent back instead, indicating the corresponding error.

The client does not need to take this response into account, but it can use this message for the internal management of the requests eventually.

The acknowledge response has the value ack for the response-type key. No additional keys appear in this message.

2.2.7.2.2.7. Replies

Any reply contains the request-state key, indicating whether the request was successfully (value succeeded) processed or whether the processing failed for any reason (value failed).

If the processing is successful, the reply contains the success key, which contains an informational message.

If the processing fails, the reply contains a list of errors which were detected. This list is not necessarily complete, i.e., if these errors are corrected, it is not guaranteed that the new request will succeed.

The errors are reported by the error-code and error-text keys. The n-th error-code key corresponds to the n-th error-text key.

2.2.8.2.2.8. Requests and their Replies

The protocol defines the following requests:

domain related

create domain

R

creates a new domain object

 

modify domain

R

modifies a domain, including owner changes

 

delete domain

R

deletes an existing domain

 

renew domain

R

extends the registration period of a domain

 

transfer domain

R

either initiates an incoming domain transfer or confirms (positively or negatively) an outgoing domain transfer

 

complete transfer

R

completes an incoming domain transfer

 

inquire domain

 

requests the data of a domain object

contact related

create contact

R

creates a new contact object

 

modify contact

R

modifies an existing contact

 

delete contact

R

deletes an existing contact

 

inquire contact

 

requests the data of a contact object

host related

create host

R

creates a new host object

 

modify host

R

modifies an existing host

 

delete host

R

deletes an existing host

 

inquire host

 

requests the data of a host object

registrar related

modify registrar

R

modifies the exposed parts of a registrar object

 

inquire registrar

 

requests the exposed data of a registrar object

transaction management

status

 

requests the status of a specified request

 

query

 

requests all the transaction identifiers of the requests of a specified period

 

The replies of the requests marked with R are recorded and can be queried by the status and query requests.

2.2.8.1.2.2.8.1. Complete Transfer Request

General information:

request type:

complete transfer

recorded:

yes

 

The complete transfer request is the final step in the process for an incoming domain transfer. The request and reply keys are identical to the create domain request.

 

Special request keys:

domain-name

M

the domain name

owner-contact

M

the new owner (approved-owner-change must be Y to come into effect)

admin-contact

M

the new administrative contact

tech-contact

M

the new technical contact

zone-contact

M

the new zone contact

approved-owner-change

M

flag, whether an owner change should be performed (see also the modify domain request)

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved.

domain-state

M

either production or reserved. Other states may not be assigned by a registrar.

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the transfer

2.2.8.2.2.2.8.2. Create Contact Request

General information:

request type:

create contact

recorded:

yes

 

The create contact request creates a new contact object in the registry’s database.

 

Special request keys:

individual

M

determines whether this contact describes an individual (Y) or an organization (N)

fname

M/D

the first name of the individual

lname

M/D

the last name of the individual

title

O/D

the title of the individual

organization

O/M

the organization (may be specified for an individual also)

address-1

M

the city-local address

address-2

O

additional address

city

M

the city where the individual/organization is located in

postal-code

M

the postal code of the city

state

O

the state where the city is located in

country

M

the country the city is located in

phone

M

the phone number

fax

O

the fax number

email

M

the e-mail address

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

handle

the handle for the contact, assigned by the server

2.2.8.3.2.2.8.3. Create Domain Request

General information:

request type:

create domain

recorded:

yes

 

The create domain request creates a new domain. The name may not exist when the request is processed.

 

Special request keys:

domain-name

M

the domain name

owner-contact

M

the owner

admin-contact

M

the administrative contact

tech-contact

M

the technical contact

zone-contact

M

the zone contact

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved.

domain-state

M

either production or reserved. Other states may not be assigned by a registrar.

period

O

the registration period. If omitted, a registry specific default period is used.

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the creation

2.2.8.4.2.2.8.4. Create Host Request

General information:

request type:

create host

recorded:

yes

 

The create host request creates a new host object in the registry’s database.

 

Special request keys:

contact

O

a contact that is responsible for the host

domain-name

M

the domain name of the host

ip-address

O

the IP address of the host

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

handle

the handle for the host, assigned by the server

2.2.8.5.2.2.8.5. Delete Contact Request

General information:

request type:

delete contact

recorded:

yes

 

The delete contact request deletes an existing contact object in the registry’s database. The object may not be referenced by other objects, i.e., may not appear in a host contact or domain contact (as the owner or the admin, technical or zone contact). The object must be managed by the registrar.

 

Special request keys:

handle

M

the contact handle of the object

(M mandatory key, O optional key, D disallowed)

2.2.8.6.2.2.8.6. Delete Domain Request

General information:

request type:

delete domain

recorded:

yes

 

The delete domain request deletes an existing domain object in the registry’s database. The object must be managed by the registrar. Depending on the registry’s policy, costs are refunded if a domain is deleted a short time after the creation.

 

Special request keys:

domain-name

M

the name of the domain to be deleted

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

costs

the costs (refunds) of the deletion

2.2.8.7.2.2.8.7. Delete Host Request

General information:

request type:

delete host

recorded:

yes

 

The delete host request deletes an existing host object in the registry’s database. The object may not be referenced by other objects, i.e., may not appear in a domain as a name server. The object must be managed by the registrar.

 

Special request keys:

handle

M

the host handle of the object

(M mandatory key, O optional key, D disallowed)

2.2.8.8.2.2.8.8. Inquire Contact Request

General information:

request type:

inquire contact

recorded:

no

 

The inquire contact request returns information about an existing contact object. Depending on the existence and the value of the list key, either the contact details or its usage in domains and hosts is returned.

 

Special request keys:

handle

M

the contact handle of the object

list

O

what kind of information should be returned. If key does not exist or is empty, then details about the contact are returned (case 1). If the value is equal to domains, a list of domains, which use this contact as the owner, the administrative, technical or zone contact, is returned (case 2). If the value is equal to hosts, a list of hosts using the object as a contact is returned (case 3).

(M mandatory key, O optional key, D disallowed)

 

Special reply keys (case 1):

handle

the handle of the object

individual

determines whether this contact describes an individual (Y) or an organization (N)

fname

the first name of the individual

lname

the last name of the individual

title

the title of the individual

organization

the organization

address-1

the city-local address

address-2

additional address

city

the city where the individual/organization is located in

postal-code

the postal code of the city

state

the state where the city is located in

country

the country the city is located in

phone

the phone number

fax

the fax number

email

the e-mail address

managing-registrar-id

the managing registrar

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification.

 

Special reply keys (case 2):

domain-name

a domain name. This key is repeated for each domain.

count

the number of domains that use the contact

 

Special reply keys (case 3):

handle

a host handle. This key is repeated for each host.

count

the number of hosts that use the contact

2.2.8.9.2.2.8.9. Inquire Domain Request

General information:

request type:

inquire domain

recorded:

no

 

The inquire domain request returns information about an existing domain object.

 

Special request keys:

domain-name

M

the name of the domain

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

domain-name

the domain name

individual

owner: determines whether this contact describes an individual (Y) or an organization (N)

fname

owner: the first name of the individual

lname

owner: the last name of the individual

title

owner: the title of the individual

organization

owner: the organization

address-1

owner: the city-local address

address-2

owner: additional address

city

owner: the city where the individual/organization is located

postal-code

owner: the postal code of the city

state

owner: the state where the city is located in

country

owner: the country the city is located in

phone

owner: the phone number

fax

owner: the fax number

email

owner: the e-mail address

owner-contact-origin

the handle of the contact which was used as the source of the owner data

admin-contact

the handle of the administrative contact

tech-contact

the handle of the technical contact

zone-contact

the handle of the zone contact

managing-registrar-id

the managing registrar

ns1-host
ns2-host
...
ns12-host

the handles of the name servers

domain-state

the current domain state

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification.

2.2.8.10.2.2.8.10. Inquire Host Request

General information:

request type:

inquire host

recorded:

no

 

The inquire host request returns information about an existing host object. Depending on the existence and the value of the list key, either the host details or its usage in domains is returned.

 

Special request keys:

handle

M

the host handle of the object

list

O

what kind of information should be returned. If key does not exist or is empty, then details about the host are returned (case 1). If the value is equal to domains, a list of domains, which use this host as a name server, is returned (case 2).

(M mandatory key, O optional key, D disallowed)

 

Special reply keys (case 1):

handle

the handle of the object

contact

a contact that is responsible for the host

domain-name

the domain name of the host

ip-address

the IP address of the host

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification.

 

Special reply keys (case 2):

domain-name

a domain name. This key is repeated for each domain.

count

the number of domains that use the host

2.2.8.11.2.2.8.11. Inquire Registrar Request

General information:

request type:

inquire registrar

recorded:

no

 

The inquire registrar  request returns some information about a registrar. If the list key is not present or has an empty value, information about the users and their public keys is returned (case 1). If the value of the list key is domains, the domains managed by the registrar are listed (case 2). If the value is hosts, the hosts managed by the registrar are listed (case 3). If the value is contacts, the contacts managed by the registrar are listed (case 4).

 

Special request keys:

handle

M

the handle of the registrar

list

O

whether the contacts, hosts or domains of the registrar should be listed

(M mandatory key, O optional key, D disallowed)

 

Special reply keys (case 1):

handle

the handle of the registrar

organization

the name of the registrar

reg-admin-permissions

the allowed request types

reg-admin-contact

the contact handle

reg-admin-auth-type

the type of the public key

reg-admin-auth-key-info

information about the public key

reg-agent-permissions

the allowed request types

reg-agent1-contact
...
reg-agent12-contact

the contact handles

reg-agent1-auth-type
...
reg-agent12-auth-type

the types of the public keys

reg-agent1-auth-key-info
...
reg-agent12-auth-key-info

information about the public keys

reg-super-permissions

the allowed request types

reg-super-contact

the contact handle

reg-super-auth-type

the type of the public key

reg-super-auth-key-info

information about the public key

reg-state

the state of the registrar

transaction-credit

the current balance of the account

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification.

 

Special reply keys (case 2):

domain-name

a domain name. This key is repeated for each domain.

count

the number of domains

 

Special reply keys (case 3):

handle

a host handle. This key is repeated for each host.

count

the number of hosts

 

Special reply keys (case 4):

handle

a contact handle. This key is repeated for each host.

count

the number of contacts

2.2.8.12.2.2.8.12. Modify Contact Request

General information:

request type:

modify contact

recorded:

yes

 

The create contact request modifies an existing contact object. The object must be managed by the registrar.

 

Special request keys:

handle

M

the handle of the contact

individual

M

determines whether this contact describes an individual (Y) or an organization (N)

fname

M/D

the first name of the individual

lname

M/D

the last name of the individual

title

O/D

the title of the individual

organization

O/M

the organization (may be specified for an individual also)

address-1

M

the city-local address

address-2

O

additional address

city

M

the city where the individual/organization is located in

postal-code

M

the postal code of the city

state

O

the state where the city is located in

country

M

the country the city is located in

phone

M

the phone number

fax

O

the fax number

email

M

the e-mail address

(M mandatory key, O optional key, D disallowed)

2.2.8.13.2.2.8.13. Modify Domain Request

General information:

request type:

modify domain

recorded:

yes

 

The modify domain  request changes contacts and name servers of the given domain. Data from the given owner contact is either copied partially or fully into the domain object, depending on the value of the approved-owner-change key. If the value is Y, all fields are copied. If the value is N, the following fields are copied: title, email, phone and fax.

 

Special request keys:

domain-name

M

the domain name

owner-contact

O

the new owner (effect depends on the approved-owner-change key; see above)

admin-contact

O*

the new administrative contact

tech-contact

O*

the new technical contact

zone-contact

O*

the new zone contact

approved-owner-change

O*

flag, whether an owner change should be performed

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved.

domain-state

O*

either production or reserved. Other states may not be assigned by a registrar.

(M mandatory key, O optional key, D disallowed)

* not changed if key is omitted

2.2.8.14.2.2.8.14. Modify Host Request

General information:

request type:

modify host

recorded:

yes

 

The modify host request modifies an existing host object. The object must be managed by the registrar.

 

Special request keys:

Contact

O

a contact that is responsible for the host

domain-name

M

the domain name of the host

ip-address

O

the IP address of the host

(M mandatory key, O optional key, D disallowed)

2.2.8.15.2.2.8.15. Modify Registrar Request

General information:

request type:

modify host

recorded:

yes

 

The modify registrar request enables the registrar to modify some aspects of his data stored in the registry system, mainly the keys and the identities of the staff working with the SRS.

 

Special request keys:

Handle

M

the handle of the registrar

Organization

O*

the name of the registrar

reg-admin-contact

O*

the contact describing the administrator

reg-admin-auth-type

O*

the type of the authorization the administrator uses

reg-admin-auth-key

O*

the public key of the administrator

reg-agent1-contact
...
reg-agent12-contact

O*

the contacts describing the agents

reg-agent1-auth-type
...
reg-agent12-auth-type

O*

the types of the authorizations of the agents

reg-agent1-auth-key
...
reg-agent12-auth-key

O*

the public keys of the agents

reg-super-contact

O*

the contact describing the super administrator

reg-super-auth-type

O*

the type of the authorization the super administrator uses

reg-super-auth-key

O*

the public key of the super administrator

(M mandatory key, O optional key, D disallowed)

* if omitted, the corresponding entry is not modified

2.2.8.16.2.2.8.16. Query Request

General information:

request type:

query

recorded:

no

 

The query request returns information about requests submitted/completed in a given period of time. Only those requests are returned, whose results were recorded previously. See the general information/recorded entries in the description of the requests whether the results are recorded or not. The requests are returned in chronological order regarding to the submission date.

 

Special request keys:

completed-before

O

if present, it restricts the output to those requests which were completed before the given date (including)

completed-after

O

if present, it restricts the output to those requests which were completed after the given date (including)

submitted-before

O

if present, it restricts the output to those requests which were submitted before the given date (including)

submitted-after

O

if present, it restricts the output to those requests which were submitted after the given date (including)

request-state

O

if present, it restricts the output to those requests which are in the given state.

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

request-transaction-id

a transaction identifier that matches the condition(s). This key is repeated for each request

count

the number of requests matching the condition(s)

2.2.8.17.2.2.8.17. Renew Domain Request

General information:

request type:

renew domain

recorded:

yes

 

The renew domain request extends the registration period of a domain.

 

Special request keys:

domain-name

M

the domain name

period

M

the extension of registration period.

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the renewal

2.2.8.18.2.2.8.18. Status Request

General information:

request type:

status

recorded:

no

 

The status request enables the client to retrieve information about requests sent to the server earlier. If the request has been finished, the result of it is returned. If the specified transaction identifier is unknown to the server, the server returns a failed request state with the error-code key indicating the problem.

 

Special request keys:

transaction-id

M

In contrast to other requests, not a new transaction identifier should be specified here, but the transaction identifier of the request to be inspected instead.

(M mandatory key, O optional key, D disallowed)

 

Special reply keys:

request-state

If the request related to the given transaction identifier does not exist, failed is returned and error code -270 is returned. If the request has been received, but not yet been processed, either pending or in-process is returned. If the request has been processed, the key contains the corresponding value of the request’s reply.

(other)

see the description of the specific request

2.2.8.19.2.2.8.19. Transfer Domain Request

General information:

request type:

transfer domain

recorded:

yes

 

The transfer domain request is used in the process of the transfer of a domain from one registrar to another registrar. The request is both used for incoming and outgoing transfers. See below for the exact process.

 

Special request keys:

domain-name

M

the domain name

action

M

the action to be performed.

(M mandatory key, O optional key, D disallowed)

2.2.9.2.2.9. Notifications

During the domain transfer process, the server sends notifications to the registrar. The notifications use the e-mail transmission variant and the payload layer. The registrar may react upon the notifications by sending normal requests to the server via one of its clients. The notification contains at least two keys:

payload-version

identifies the version of the payload used for the notification

notification-type

the type of notification

2.2.9.1.2.2.9.1. Init-Transfer Notification

General information:

notification type:

init-transfer

The init-transfer notification is sent to the loosing registrar to inform that a domain transfer process has been started for the given domain.

 

Additional keys:

domain-name

the name of the domain to be transferred

gaining-registrar

the registrar who initiated the transfer

time-out-date

point of time until the loosing registrar can react

2.2.9.2.2.2.9.2. Transfer-Acknowledge Notification

General information:

notification type:

transfer-acknowledge

The transfer-acknowledge notification is sent to the gaining registrar to inform about the decision of the loosing registrar (or the registry in case of a timeout).

 

Additional keys:

domain-name

the name of the domain to be transferred

transfer-approved

tells whether the loosing registrar has acknowledged the transfer positively or negatively.

time-out-date

point of time until the gaining registrar can react

2.2.9.3.2.2.9.3. Transfer-Finish Notification

General information:

notification type:

transfer-finish

The transfer-finished notification is sent to the loosing registrar (and to the gaining registrar in case of a time-out) to inform about the final result of the domain transfer process.

 

Additional keys:

domain-name

the name of the domain

transfer-performed

tells whether the transfer has been performed or not

 

2.2.10.2.2.10. Common Data Types

2.2.10.1.2.2.10.1. Handles

SRSP specific handles share a common format: a prefix followed by a number. The prefix is CORE-, COCO- and COHO- for registrar, contact and host handles, respectively. The case of the prefixes does not matter. Handles are always assigned by the server (or, for the registrar handle, by the registry staff).

2.2.10.2.2.2.10.2. Domain Names

Domain names are always fully qualified domain names (see [RFC1035]) without a trailing dot.

2.2.10.3.2.2.10.3. IP Addresses

The IP Addresses are IPv4 addresses in the form A.B.C.D, where A, B, C, D are numbers between 0 and 255.

2.2.10.4.2.2.10.4. Dates/Times

A date and time always appear in combination. The time zone is Greenwich Mean Time (GMT). The exact format is

YYYYMMDD hh:mm:ss

where YYYY is four-digit year, MM is the two-digit month, DD is the two digit day, hh is the two digit hour, mm is the two digit minute and ss is the two digit second. Date and time are separated by exactly one space character (0x20).

2.2.10.5.2.2.10.5. Phone and Fax Numbers

It is strongly recommended (although not required) that telephone and Fax numbers are specified in the international format, i.e., starting with a plus sign, followed by the international area code, by the area code used in the specific country and by the local subscriber number.

2.2.10.6.2.2.10.6. E-Mail Addresses

E-mail addresses should conform to the format specified in [RFC822], without any comments.

2.2.10.7.2.2.10.7. Billing Units

CORE uses a fictional currency for the registrars’ accounts. It is called RCU (registry currency unit). It is a number with two fractional digits.

2.2.11.2.2.11. Description of the Keys

2.2.11.1.2.2.11.1. Action Key

name:

action

used by:

client

format/values:

either init-transfer, abort-transfer, positive-transfer-ack or negative-transfer-ack (case insensitive)

description:

The action to be performed in a domain transfer process.

2.2.11.2.2.2.11.2. Address Keys

name:

address-1
address-2

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies a contact’s address.

2.2.11.3.2.2.11.3. Admin-Contact Key

name:

admin-contact

used by:

client, server

format/values:

contact handle

description:

Administrative contact (of a domain).

2.2.11.4.2.2.11.4. Approved-Owner-Change Key

name:

approved-owner-change

used by:

client

format/values:

Y or N (case insensitive)

description:

If Y (yes), it signals that the requirements for an owner change have been fulfilled by the registrar and that the owner data of the domain should be updated by the given owner contact handle. If N (no), most of the previous owner data is retained. See the modify domain request for details.

2.2.11.5.2.2.11.5. City Key

name:

city

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the city where the contact is located in.

2.2.11.6.2.2.11.6. Completed-Before Key

name:

completed-before

used by:

client

format/values:

date

description:

Specifies the upper bound for the completion date of a request to be found by the query request.

2.2.11.7.2.2.11.7. Completed-Since Key

name:

completed-since

used by:

client

format/values:

date

description:

Specifies the lower bound for the completion date of a request to be found by the query request.

2.2.11.8.2.2.11.8. Contact Key

name:

contact

used by:

client, server

format/values:

contact handle

description:

(Administrative, technical) contact of the host.

2.2.11.9.2.2.11.9. Costs Key

name:

costs

used by:

server

format/values:

RCU value

description:

Specifies the amount of RCUs which were deducted from the registrar’s account. A positive value is a debit, a negative value a credit.

2.2.11.10.2.2.11.10. Count Key

name:

count

used by:

server

format/values:

positive number

description:

The number of objects that meet the criteria (inquire requests in combination with the list key, or the query request). The value is not necessarily identical with the number of object handles/domain names returned: the actual number of objects listed may be reduced due to the registry policy.

2.2.11.11.2.2.11.11. Country Key

name:

country

used by:

client, server

format/values:

text string, no more than 50 characters; although not required, it is strongly recommended to use the ISO two letter code [ISO3166]

description:

Specifies the country where the contact is located in.

2.2.11.12.2.2.11.12. Created Key

name:

created

used by:

server

format/values:

date

description:

Specifies the date when the object was created.

2.2.11.13.2.2.11.13. Created-By Key

name:

created-by

used by:

server

format/values:

registrar handle

description:

Specifies the handle of the registrar who created the object.

2.2.11.14.2.2.11.14. Domain-Name Key

name:

domain-name

used by:

client, server, notification

format/values:

domain name

description:

For domain objects the name of the domain, for host objects the DNS name of the host.

2.2.11.15.2.2.11.15. Domain-State Key

name:

domain-state

used by:

client, server

format/values:

either reserved, production, expired or hold (case insensitive)

description:

The state of the domain. See the description of the domain object for details.

2.2.11.16.2.2.11.16. EMail Key

name:

email

used by:

client, server

format/values:

text string, containing a single valid e-mail address

description:

Specifies an e-mail address.

2.2.11.17.2.2.11.17. Error-Code Key

name:

error-code

used by:

server

format/values:

integer number (positive or negative)

description:

Indicates a specific error. See below for the error codes.

2.2.11.18.2.2.11.18. Error-Text Key

name:

error-text

used by:

server

format/values:

text string

description:

Contains a human readable explanation of the error. The string is meant for debugging purposes. The client should not attempt to parse the contents of this string. Therefore, no description of the various texts are given in this document.

2.2.11.19.2.2.11.19. Expiration-Date Key

name:

expiration-date

used by:

server

format/values:

date

description:

Specifies the date when the domain expires.

2.2.11.20.2.2.11.20. Fax Key

name:

fax

used by:

client, server

format/values:

text string, containing a phone number of a fax machine

description:

Specifies a fax number.

2.2.11.21.2.2.11.21. FName Key

name:

fname

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the first name of an individual.

2.2.11.22.2.2.11.22. Gaining-Registrar Key

name:

gaining-registrar

used by:

notification

format/values:

registrar handle

description:

Specifies the registrar who wants to gain a domain in a domain transfer process.

2.2.11.23.2.2.11.23. Handle Key

name:

handle

used by:

client, server

format/values:

handle

description:

Specifies the handle of the target object to be modified, deleted or inquired (client) or the handle that has been assigned by the server

2.2.11.24.2.2.11.24. Individual Key

name:

individual

used by:

client, server

format/values:

either Y or N (case insensitive)

description:

Specifies whether a contact describes an individual (Y) or an organization (N).

2.2.11.25.2.2.11.25. IP-Address Key

name:

ip-address

used by:

client, server

format/values:

An IP address

description:

Specifies the IP address of a host.

2.2.11.26.2.2.11.26. Last-Modified Key

name:

last-modified

used by:

server

format/values:

date

description:

Specifies the date when the object was modified at last.

2.2.11.27.2.2.11.27. Last-Modified-By Key

name:

last-modified-by

used by:

server

format/values:

registrar handle

description:

Specifies the handle of the registrar who modified the object at last.

2.2.11.28.2.2.11.28. List Key

name:

list

used by:

client

format/values:

text string, containing either domains, contacts or hosts (case insensitive)

description:

Specifies on inquiries which referencing objects should be listed.

2.2.11.29.2.2.11.29. LName Key

name:

lname

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the last name of an individual.

2.2.11.30.2.2.11.30. Managing-Registrar-ID Key

name:

managing-registrar-id

used by:

server

format/values:

registrar handle

description:

Identifies the managing registrar of a domain, contact or host object

2.2.11.31.2.2.11.31. Notification-Type Key

name:

notification-type

used by:

notification

format/values:

text string, containing either init-transfer, transfer—acknowledge or transfer-finish (case insensitive)

description:

Specifies the type of notification.

2.2.11.32.2.2.11.32. NS-Host Keys

name:

ns1-host
ns2-host
...
ns12-host

used by:

client, server

format/values:

host handle

description:

Specifies the name servers of a domain.

2.2.11.33.2.2.11.33. Organization Key

name:

organization

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the name of the organization.

2.2.11.34.2.2.11.34. Owner-Contact Key

name:

owner-contact

used by:

client

format/values:

contact handle

description:

Owner (of the domain).

2.2.11.35.2.2.11.35. Owner-Contact-Origin Key

name:

owner-contact-origin

used by:

server

format/values:

contact handle

description:

Identifies the origin of the owner data stored in the domain object.

2.2.11.36.2.2.11.36. Payload-Version Key

name:

payload-version

used by:

client (the server does not use this key, since it always uses the same payload version as the client used in its request), notification

format/values:

N.M

where N and M are positive numbers

description:

Specifies the version number of the payload. The payload specified in this document has the version number 1.1.

2.2.11.37.2.2.11.37. Period Key

name:

period

used by:

client

format/values:

positive number indicating the number of years

description:

Specifies the registration period of a domain (or its extension).

2.2.11.38.2.2.11.38. Phone Key

name:

phone

used by:

client, server

format/values:

text string, containing a phone number

description:

Specifies a phone number

2.2.11.39.2.2.11.39. Postal-Code Key

name:

postal-code

used by:

client, server

format/values:

text string, containing the postal code

description:

Specifies the postal code of the related city key.

2.2.11.40.2.2.11.40. Reg-Admin-Auth-Key Key

name:

reg-admin-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key which the registrar uses for administration purposes.

2.2.11.41.2.2.11.41. Reg-Admin-Auth-Key-Info Key

name:

reg-admin-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value> [ , <param> = <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.42.2.2.11.42. Reg-Admin-Auth-Type Key

name:

reg-admin-auth-type

used by:

client

format/values:

must be pgp5 (case insensitive)

description:

The type of the cryptographic key specified with the corresponding reg-admin-auth-key.

2.2.11.43.2.2.11.43. Reg-Admin-Contact Key

name:

reg-admin-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar administration.

2.2.11.44.2.2.11.44. Reg-Admin-Permissions Key

name:

reg-admin-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for the corresponding entity.

2.2.11.45.2.2.11.45. Reg-Agent-Auth-Key Keys

name:

reg-agent1-auth-key
reg-agent2-auth-key
...
reg-agent12-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key which the registrar’s staff uses for the daily work.

2.2.11.46.2.2.11.46. Reg-Agent-Auth-Key-Info Key

name:

reg-agent-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value> [ , <param> = <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.47.2.2.11.47. Reg-Agent-Auth-Type Keys

name:

reg-agent1-auth-type
reg-agent2-auth-type
...
reg-agent12-auth-type

used by:

client

format/values:

must be pgp5 (case insensitive)

description:

The type of the cryptographic key specified with the corresponding reg-agentN-auth-key.

2.2.11.48.2.2.11.48. Reg-Agent-Contact Keys

name:

reg-agent1-contact
reg-agent2-contact
...
reg-agent12-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar staff.

2.2.11.49.2.2.11.49. Reg-Agent-Permissions Key

name:

reg-agent-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for the corresponding entity.

2.2.11.50.2.2.11.50. Reg-State Key

name:

reg-state

used by:

client, server

format/values:

one of active, suspended or defunct (case insensitive)

description:

The registrar’s state

2.2.11.51.2.2.11.51. Reg-Super-Auth-Key Key

name:

reg-super-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key of the registrar’s super contact.

2.2.11.52.2.2.11.52. Reg-Super-Auth-Key-Info Key

name:

reg-super-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value> [ , <param> = <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.53.2.2.11.53. Reg-Super-Auth-Type Key

name:

reg-super-auth-type

used by:

client

format/values:

must be pgp5 (case insensitive)

description:

The type of the cryptographic key specified with the corresponding reg-super-auth-key.

2.2.11.54.2.2.11.54. Reg-Super-Contact Key

name:

reg-super-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar’s super contact.

2.2.11.55.2.2.11.55. Reg-Super-Permissions Key

name:

reg-super-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for the corresponding entity.

2.2.11.56.2.2.11.56. Registrar-ID Key

name:

registrar-id

used by:

client, server

format/values:

registrar handle

description:

This key identifies the registrar. The handle is assigned by the registry staff.

2.2.11.57.2.2.11.57. Request-Transaction-ID Key

name:

request-transaction-id

used by:

server

format/values:

transaction identifier (see transaction-id key)

description:

The transaction identifier of a previously received request. This key is used in the reply of a query request.

2.2.11.58.2.2.11.58. Request-Type Key

name:

request-type

used by:

client

format/values:

The value consists of a sequence of words, separated by whitespace. A word is a sequence of the letters A to Z. The case of the words is irrelevant

description:

The request type specifies the action the server should perform on behalf of the client.

2.2.11.59.2.2.11.59. Request-State Key

name:

request-state

used by:

server

format/values:

one of the following terms: pending, in-process, succeeded, failed

description:

Returns the processing state of a request. The meanings of the values are:

pending               the request has been received and is currently waiting to be processed

in-process           the request is being processed

succeeded          the request has been processed successfully. Changes were made according to the request

failed                    the processing of the request failed. No changes, even not partially, were made

2.2.11.60.2.2.11.60. Response-Type Key

name:

response-type

used by:

server

format/values:

either ack or reply

description:

This key tells the client whether the response contains an intermediate confirmation of the reception of the request (acknowledge, ack) or the final result of the request (reply)

2.2.11.61.2.2.11.61. State Key

name:

state

used by:

client, server

format/values:

text string

description:

The state or territory where the contact is located in.

2.2.11.62.2.2.11.62. Submitted-Before Key

name:

submitted-before

used by:

client

format/values:

date

description:

Specifies the upper bound for the submission date of a request to be found by the query request.

2.2.11.63.2.2.11.63. Submitted-Since Key

name:

submitted-since

used by:

client

format/values:

date

description:

Specifies the lower bound for the submission date of a request to be found by the query request.

2.2.11.64.2.2.11.64. Success Key

name:

success

used by:

server

format/values:

text string

description:

A human readable comment to the successful processing of a request. The string is meant for debugging purposes. The client should not attempt to parse the contents of this string. Therefore, no description of the various texts are given in this document.

2.2.11.65.2.2.11.65. Tech-Contact Key

name:

tech-contact

used by:

client, server

format/values:

contact handle

description:

Technical contact (of a domain).

2.2.11.66.2.2.11.66. Time-Out-Date Key

name:

time-out-date

used by:

notification

format/values:

date

description:

The deadline until the server expects a reaction from the registrar.

2.2.11.67.2.2.11.67. Title Key

name:

title

used by:

client, server

format/values:

text string, no more than 50 characters

description:

The title of the contact.

2.2.11.68.2.2.11.68. Transaction-Credit Key

name:

title

used by:

server

format/values:

RCU value

description:

The balance of the registrar’s account.

2.2.11.69.2.2.11.69. Transaction-ID Key

name:

transaction-id

used by:

client, server

format/values:

may consist of a sequence of printable, non-whitespace characters, no less than one character and no more than forty characters

description:

The transaction identifier is generated by the client. It is not required, but strongly recommended that the identifier is registrar-unique, since the status request cannot return any information for multiply used transaction identifiers.

2.2.11.70.2.2.11.70. Transfer-Approved Key

name:

transfer-approved

used by:

notification

format/values:

either Y or N (case insensitive)

description:

Specifies whether the loosing registrar approves (Y) or declines (N) the domain transfer.

2.2.11.71.2.2.11.71. Transfer-Performed Key

name:

transaction-performed

used by:

notification

format/values:

either Y or N (case insensitive)

description:

Specifies whether the transfer has finally been performed (Y) or not (N).

2.2.11.72.2.2.11.72. Zone-Contact Key

name:

zone-contact

used by:

client, server

format/values:

contact handle

description:

Contact who is responsible for the maintenance of the DNS zone.

2.2.12.2.2.12. Error Codes

-100

empty request

-101

transaction-id not found

-102

registrar-id not found or invalid

-103

request-type not found or invalid

-104

no permission to execute this request

-105

field payload version not found or invalid

-106

not enough credits for this request

-107

duplicate key in request

-108

no registrar-contact record found for registrar-id and PGP keyid

-109

no registrar-handle record found or registrar-handle is invalid

-110

value not found or invalid

-111

mandatory key not found

-112

value exceeds maximum field length

-113

mandatory key can not be empty in modification request.

-114

invalid top level domain name

-117

value is not a valid date

-118

host-handles must be unique for each domain

-130

host cannot be deleted because of references to existing domains.

-131

contact cannot be deleted because of references to existing objects.

-150

not manager of this contact

-151

illegal flag

-160

domain name is already registered.

-180

not manager of this domain

-200

PGP key could not be added, maybe wrong format or invalid

-201

PGP keyid is already in use for that registrar

-251

reg-admin, reg-agent or reg-super key sets  incomplete

-270

no request with the given transaction-id exists

-310

host-handle not found or invalid

-311

not manager of this host

-350

domain does not exist

-351

domain is not scheduled for transfer

-352

not owner of this transfer, permission denied

-354

transfer for that domain is already in progress

2.3.2.3. Domain Transfer Process

The domain transfer process involves three parties — the gaining registrar, the registry and the loosing registrar. Both registrars negotiate about the transfer, the registry only being the mediator in this process.

Steps in a domain transfer where the loosing registrar agrees to a transfer:

gaining registrar

 

registry

 

loosing registrar

 

¾request®
transfer domain [action: init-transfer]

 

 

 

 

¬reply¾

registry checks whether domain exists and can be transferred

¾notification®
init-transfer

 

 

 

 

¬request¾
transfer domain [action: positive-transfer-ack]

registrar determines whether customer wants to change registrar, agrees

 

¬notification¾
transfer-acknowledge [transfer-approved: Y]

registry checks whether process is still in progress

 

 

registrar finishes process

¾request®
complete-transfer

 

 

 

 

¬reply¾

registry performs changes and notifies loosing registrar

¾notification®
transfer-finish [transfer-performed: Y]

 

 

Steps in a domain transfer where the loosing registrar declines a transfer:

gaining registrar

 

registry

 

loosing registrar

 

¾request®
transfer domain [action: init-transfer]

 

 

 

 

¬reply¾

registry checks whether domain exists and can be transferred

¾notification®
init-transfer

 

 

 

 

¬request¾
transfer domain [action: negative-transfer-ack]

registrar determines whether customer wants to change registrar, declines

 

¬notification¾
transfer-acknowledge [transfer-approved: N]

registry checks whether process is still in progress

¾notification®
transfer-finish [transfer-performed: N]

 

 

Steps in a domain transfer where the gaining registrar aborts a transfer before the loosing registrar makes its decision:

gaining registrar

 

registry

 

loosing registrar

 

¾request®
transfer domain [action: init-transfer]

 

 

 

 

¬reply¾

registry checks whether domain exists and can be transferred

¾notification®
init-transfer

 

registrar aborts process

 

 

 

 

 

¾request®
transfer domain [action: abort-transfer]

 

 

 

 

¬reply¾

registry aborts the process

¾notification®
transfer-finish [transfer-performed: N]

 

 

Steps in a domain transfer where the gaining registrar aborts a transfer despite of an agreement of the loosing registrar:

gaining registrar

 

registry

 

loosing registrar

 

¾request®
transfer domain [action: init-transfer]

 

 

 

 

¬reply¾

registry checks whether domain exists and can be transferred

¾notification®
init-transfer

 

 

 

 

¬request¾
transfer domain [action: positive-transfer-ack]

registrar determines whether customer wants to change registrar, agrees

 

¬notification¾
transfer-acknowledge [transfer-approved: Y]

registry checks whether process is still in progress

 

 

registrar aborts process

¾request®
transfer domain [action: abort-transfer]

 

 

 

 

¬reply¾

registry aborts the process

¾notification®
transfer-finish [transfer-performed: N]

 

 

If the loosing registrar fails to respond upon the init-transfer notification before reaching the time-out date, the registry decides on behalf of the registrar, depending on the registry’s policy. The registry behaves as if it received a transfer domain request with either positive or negative transfer acknowledge.

If the gaining registrar fails to respond upon the transfer-acknowledge notification before reaching the time-out date, the registry behaves as if it received a transfer domain request with the abort-transfer action. Additionally, it sends a transfer-finish notification to the gaining registrar.

 

gaining registrar

 

registry

 

loosing registrar

¾ ¾ same as above ¾ ¾

 

¬notification¾
transfer-acknowledge [transfer-approved: Y]

registry checks whether process is still in progress

 

 

 

¬notification¾
transfer-finish [transfer-performed: N]

registry aborts the process due to time-out

¾notification®
transfer-finish [transfer-performed: N]

 

 

 

A. References

[PGP5]

http://www.pgp.com

[RFC822]

RFC 822, Standard for the format of ARPA Internet text messages

[RFC1035]

RFC 1035, Domain names - implementation and specification

[RFC1847]

RFC 1847, Security Multiparts for MIME: Multipart/Signed andMultipart/Encrypted

[RFC2015]

RFC 2015, MIME Security with Pretty Good Privacy (PGP)

[IANA-PORTS]

http://www.isi.edu/in-notes/iana/assignments/port-numbers

[ISO3166]

http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

 

B. Glossary

CORE

Council of Registrars

CNO

COM, NET and ORG (domains)

registry

the entity which operates the central database of registered domains (and additional data, eventually)

registrar

the entity which registers domains on behalf of customers and resellers

request

a message the client sends to the server

response

a message the server sends to the client

reply

the result of a request

notification

a message sent by the server to inform the registrar about an event or change of state; not directly related to a request

message

a data packet containing the payload and the digital signature

 

 



[1] encryption was considered, but some countries (e.g. France) had a very restrictive policy on cryptography at that time

[2] there is one exception: the owner of a domain is stored in a copy, although he is also referenced by a handle. See the description of the domain object for details.

[3] this is any printable character except double quote " and backslash \

[4] this is any printable character except the colon :